home *** CD-ROM | disk | FTP | other *** search
/ C/C++ Users Group Library 1996 July / C-C++ Users Group Library July 1996.iso / vol_400 / 425_01 / tar / diszip.c < prev    next >
Text File  |  1994-03-29  |  38KB  |  1,029 lines
  1. /* The following is derived from 'funzip' utility sources
  2.  * (funzip.c & inflate.c files) which are written and
  3.  * gracefully put into public domain by Mark Adler.
  4.  * You can find original texts in Info-Zip 'unzip' distribution.
  5.  */
  6.  
  7. /*#define PKZIP_BUG_WORKAROUND*/
  8. #define V314_BUG_WORKAROUND
  9.  
  10. #include "modern.h"
  11. #include "stdinc.h"
  12. #ifdef MODERN
  13. #  include <string.h>
  14. #else
  15.    char *malloc();
  16. #endif
  17. #include "zipdefs.h"
  18. #include "zippipe.h"
  19. #include "crc32.h"
  20.  
  21. #ifndef max
  22. #  define max(a,b) (((a) > (b)) ? (a) : (b))
  23. #endif
  24.  
  25. /* Minix needs it after all the other includes (?) */
  26. #include <stdio.h>
  27.  
  28. #define AT_EOF 0x80 /* End of data achieved */
  29. #define INITED 0x40 /* Header processed */
  30. #define METHOD 0x03 /* Inflate method mask */
  31. #define IBEGIN 0x20 /* Trees (or stored length) processed */
  32. #define ICFLAG 0x10 /* Copy pending */
  33.  
  34. static uch zipstate = 0;
  35. static int (*getb) __ARGS__((void)) = (int(*)())0;
  36.  
  37. #define readbyte() (*getb)()
  38. #define nextbyte() (*getb)()
  39.  
  40. #define PF_CRYPT 1 /* PKWare flag fields */
  41. #define PF_ATEOF 8
  42. #define PF_ERROR 0x1ff0
  43.  
  44. #define GF_ASCII   1 /* GNU flag fields */
  45. #define GF_CONT    2
  46. #define GF_EXTRA   4
  47. #define GF_FNAME   8
  48. #define GF_COMMENT 0x10
  49. #define GF_CRYPT   0x20
  50. #define GF_ERROR   0xC0
  51.  
  52. static char ziptype = 0;
  53. static ush zipflags, zmethod;
  54. static ulg crc32val, srcsize;
  55. static uch *slide = (uch*)0;
  56. static ulg outsiz;  /* total bytes written to out */
  57. static char *outbuf;
  58. static ush  outpos; /* output posiztion in slide */
  59.  
  60. /*
  61.    Inflate deflated (PKZIP's method 8 compressed) data.  The compression
  62.    method searches for as much of the current string of bytes (up to a
  63.    length of 258) in the previous 32K bytes.  If it doesn't find any
  64.    matches (of at least length 3), it codes the next byte.  Otherwise, it
  65.    codes the length of the matched string and its distance backwards from
  66.    the current position.  There is a single Huffman code that codes both
  67.    single bytes (called "literals") and match lengths.  A second Huffman
  68.    code codes the distance information, which follows a length code.  Each
  69.    length or distance code actually represents a base value and a number
  70.    of "extra" (sometimes zero) bits to get to add to the base value.  At
  71.    the end of each deflated block is a special end-of-block (EOB) literal/
  72.    length code.  The decoding process is basically: get a literal/length
  73.    code; if EOB then done; if a literal, emit the decoded byte; if a
  74.    length then get the distance and emit the referred-to bytes from the
  75.    sliding window of previously emitted data.
  76.  
  77.    There are (currently) three kinds of inflate blocks: stored, fixed, and
  78.    dynamic.  The compressor outputs a chunk of data at a time, and decides
  79.    which method to use on a chunk-by-chunk basis.  A chunk might typically
  80.    be 32K to 64K, uncompressed.  If the chunk is uncompressible, then the
  81.    "stored" method is used.  In this case, the bytes are simply stored as
  82.    is, eight bits per byte, with none of the above coding.  The bytes are
  83.    preceded by a count, since there is no longer an EOB code.
  84.  
  85.    If the data is compressible, then either the fixed or dynamic methods
  86.    are used.  In the dynamic method, the compressed data is preceded by
  87.    an encoding of the literal/length and distance Huffman codes that are
  88.    to be used to decode this block.  The representation is itself Huffman
  89.    coded, and so is preceded by a description of that code.  These code
  90.    descriptions take up a little space, and so for small blocks, there is
  91.    a predefined set of codes, called the fixed codes.  The fixed method is
  92.    used if the block ends up smaller that way (usually for quite small
  93.    chunks), otherwise the dynamic method is used.  In the latter case, the
  94.    codes are customized to the probabilities in the current block, and so
  95.    can code it much better than the pre-determined fixed codes can.
  96.  
  97.    The Huffman codes themselves are decoded using a mutli-level table
  98.    lookup, in order to maximize the speed of decoding plus the speed of
  99.    building the decoding tables.  See the comments below that precede the
  100.    lbits and dbits tuning parameters.
  101.  */
  102.  
  103. /*
  104.    Notes beyond the 1.93a appnote.txt:
  105.  
  106.    1. Distance pointers never point before the beginning of the output
  107.       stream.
  108.    2. Distance pointers can point back across blocks, up to 32k away.
  109.    3. There is an implied maximum of 7 bits for the bit length table and
  110.       15 bits for the actual data.
  111.    4. If only one code exists, then it is encoded using one bit.  (Zero
  112.       would be more efficient, but perhaps a little confusing.)  If two
  113.       codes exist, they are coded using one bit each (0 and 1).
  114.    5. There is no way of sending zero distance codes--a dummy must be
  115.       sent if there are none.  (History: a pre 2.0 version of PKZIP would
  116.       store blocks with no distance codes, but this was discovered to be
  117.       too harsh a criterion.)  Valid only for 1.93a.  2.04c does allow
  118.       zero distance codes, which is sent as one code of zero bits in
  119.       length.
  120.    6. There are up to 286 literal/length codes.  Code 256 represents the
  121.       end-of-block.  Note however that the static length tree defines
  122.       288 codes just to fill out the Huffman codes.  Codes 286 and 287
  123.       cannot be used though, since there is no length base or extra bits
  124.       defined for them.  Similarily, there are up to 30 distance codes.
  125.       However, static trees define 32 codes (all 5 bits) to fill out the
  126.       Huffman codes, but the last two had better not show up in the data.
  127.    7. Unzip can check dynamic Huffman blocks for complete code sets.
  128.       The exception is that a single code would not be complete (see #4).
  129.    8. The five bits following the block type is really the number of
  130.       literal codes sent minus 257.
  131.    9. Length codes 8,16,16 are interpreted as 13 length codes of 8 bits
  132.       (1+6+6).  Therefore, to output three times the length, you output
  133.       three codes (1+1+1), whereas to output four times the same length,
  134.       you only need two codes (1+3).  Hmm.
  135.   10. In the tree reconstruction algorithm, Code = Code + Increment
  136.       only if BitLength(i) is not zero.  (Pretty obvious.)
  137.   11. Correction: 4 Bits: # of Bit Length codes - 4     (4 - 19)
  138.   12. Note: length code 284 can represent 227-258, but length code 285
  139.       really is 258.  The last length deserves its own, short code
  140.       since it gets used a lot in very redundant files.  The length
  141.       258 is special since 258 - 3 (the min match length) is 255.
  142.   13. The literal/length and distance code bit lengths are read as a
  143.       single stream of lengths.  It is possible (and advantageous) for
  144.       a repeat code (16, 17, or 18) to go across the boundary between
  145.       the two sets of lengths.
  146.  */
  147. /* Huffman code lookup table entry--this entry is four bytes for machines
  148.    that have 16-bit pointers (e.g. PC's in the small or medium model).
  149.    Valid extra bits are 0..13.  e == 15 is EOB (end of block), e == 16
  150.    means that v is a literal, 16 < e < 32 means that v is a pointer to
  151.    the next table, which codes e - 16 bits, and lastly e == 99 indicates
  152.    an unused code.  If a code with e == 99 is looked up, this implies an
  153.    error in the data. */
  154.  
  155. #define EOB     15
  156. #define LITERAL 16
  157. #define BAD     99
  158.  
  159. typedef struct _huft {
  160.   uch e; /* number of extra bits or operation */
  161.   uch b; /* number of bits in this code or subcode */
  162.   union {
  163.     ush n; /* literal, length base, or distance base */
  164.     struct _huft *t; /* pointer to next level of table */
  165.   } v;
  166. } huft;
  167.  
  168. /* Function prototypes */
  169. static void huft_free  __ARGS__((huft **));
  170. static int  huft_build __ARGS__((unsigned *, unsigned, unsigned, ush *, ush *,
  171.                                  huft **, int *));
  172. static void copyout __ARGS__((void));
  173. static ush getbits __ARGS__((ush));
  174. static int decode  __ARGS__((unsigned *, huft *, int));
  175. static int inflate_codes __ARGS__((huft *, huft *, int, int, unsigned));
  176. static int inflate_dynamic __ARGS__((unsigned));
  177. static int inflate_fixed   __ARGS__((unsigned));